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(i\ Real party in interest 

The real party in interest is the assignee International Business Machines 
Corporation. 
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(ii) Related appeals and interferences 

There are no known appeals, judicial proceedings or interferences that may be 
related to, directly affect or be directly affected by or have a bearing on the Board's 
decision in the instant appeal. 
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(Hi) Status of claims 

Claims 1-7 and 1 1-18 are rejected. Claims 8-10 are canceled. 

Appeal is made to the Board of Patent Appeals and Interferences from the 
decision dated August 3, 2007 of the primary examiner finally rejecting claims 1-7 and 
11-18. The claims on appeal, i.e., claims 1-7 and 11-18, are set forth in the "Claims 
appendix". 

Claims 8-10 were canceled in the Amendment filed on September 24, 2007. The 
Advisory Action dated October 15, 2007 echoed the canceled status of these claims. 
Consequently, claims 8-10 are not on appeal. 
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(iv) Status of Amendments 

The only amendment filed subsequent to the final rejection was acted on by the 
examiner. The Amendment after Final, which was filed on September 24, 2007, was 
entered as indicated in the Advisory Action dated October 15, 2007. As noted in the 
Advisory Action, the Amendment after Final cancelled claims 8-10. 



Docket No.: DE920020019US1 
Serial No.: 10/624,353 



7 



PATENT 
APPEAL BRIEF 



(v) Summary of claimed subject matter 

The present application contains three independent claims (i.e., claims 1,11 and 
18). As defined in independent claims 1 and 18, the present invention is directed to a 
method for streaming a media file over a distributed information system to a client 
computer system running a browser application. As defined in independent claim 1 1, the 
present invention is directed to a computer-readable program stored on a computer- 
readable medium. 

Because independent claims 1 and 1 1 set forth identical steps - claim 1 in the 
context of a method and claim 1 1 in the context of a computer-readable program - these 
claims are summarized together below. Independent claim 18, which sets forth 
limitations not found in the other independent claims, is summarized separately below. 

The present invention as defined in independent claims 1 and 1 1 requires a step of 
receiving a request for a particular media file from a client computer. See, for example, 
the discussion at page 11, lines 14-25 of the specification with respect to a HTTP request 
URL (arrow 152) received by a metadata server 104 from a web client 102. The HTTP 
request URL points to a media file itself. The receiving step, as further defined claims 1 
and 1 1, comprises the steps of intercepting a download request for the actual media file 
and reinterpreting the download request into a request for receiving a corresponding 
metafile. See, for example, the discussion at page 12, lines 1-5 of the specification with 
respect to intercepting/reinterpreting the HTTP request. 

The present invention as also defined in independent claims 1 and 1 1 requires a 
step of providing a metafile that contains information about the identification, location 
and format of the media file. See, for example, the discussion at page 12, line 1 - page 
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13, line 3 of the specification with respect to a HTTP protocol handler 132 (component of 
the metadata server 104), working in conjunction with a metadata generator 136 or a 
metadata query component 138, to build a HTTP response that contains streaming 
metadata. See also, for example, the discussion at page 13, lines 12-14 of the 
specification with respect to information contained in the streaming metadata, such as 
which file to stream (identification), which streaming server to contact (location), which 
streaming protocol to use (format). 

The present invention as further defined in independent claims 1 and 1 1 requires a 
step of returning the metafile back to the client computer. See, for example, the 
discussion at page 13, lines 4-6 of the specification with respect to transferring the HTTP 
response that contains the streaming metadata from a network interface 134 on the 
metadata server 104 to a network interface 124 on the web client 102 (arrow 162). 

Another aspect of the present invention, as defined in each of dependent claims 5 
and 15 (which respectively depend directly from independent claims 1 and 1 1), is that the 
step of reinterpreting the download request includes the step of checking predefined filter 
criteria determining of whether or not a metafile is to be returned instead of the requested 
media file. See, for example, the discussion at page 7, lines 8-14 and lines 24-28; page 
8, lines 3-6; and page 12, lines 1-13 of the specification with respect to redirecting all 
HTTP requests matching a filter criteria to the metadata generator 136 or metadata query 
component 138. As an illustrative example, this discussion refers to building the filter 
criteria from a list of media format file extensions. 

Yet another aspect of the present invention, as defined independent claim 1 8, is 
streaming a media file over a distributed information system to a client computer by 
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sequentially interacting (e.g., arrows 152, 162, 170 and 176, as summarized below) with 
two different servers the first being a metadata server and the second being a streaming 
server. See, for example, the discussion of the web client 102, the metadata server 104 
and the delivery server 106 at pages 10-14 of the specification. It is important to note that 
the specification explicitly defines a "server" as a computer that provides some service 
for other computers connected to it via a network. See, specification, page 2, lines 16-19. 
See also, specification, page 10, lines 14-15 and page 11, lines 1-2. 

Hence, the present invention, as defined in independent claim 18, requires the use 
of two distinct servers (computer systems), i.e., the metadata server and the streamer 
server. This arrangement is advantageous in several respects. For example, one metadata 
server may cooperate with multiple delivery servers in order to perform load balancing. 
See, for example, the discussion of load balancing at page 6, lines 18-22 and page 1 1, 
lines 4-7 of the specification. 

The present invention as defined in independent claim 18 requires a step of 
receiving, at a metadata server, a request for a particular media file from a client 
computer. See, for example, the discussion at page 1 1, lines 14-25 of the specification 
with respect to a HTTP request URL (arrow 152) received by a metadata server 104 from 
a web client 102. The HTTP request URL points to a media file itself. The receiving 
step, as further defined in claim 18, comprises the steps of intercepting a download 
request for the actual media file and reinterpreting the download request as a request for 
receiving a corresponding metafile. See, for example, the discussion at page 12, lines 1-5 
of the specification with respect to intercepting/reinterpreting the HTTP request. 
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The present invention as also defined in independent claim 18 requires a step of 
providing, at the metadata server, a metafile and a MIME-type, wherein the metafile 
contains information about the identification, location and format of the media file. See, 
for example, the discussion at page 12, line 1 - page 13, line 3 of the specification with 
respect to a HTTP protocol handler 132 (component of the metadata server 104) working 
in conjunction with a metadata generator 1 36 or a metadata query component 1 38 builds 
a HTTP response that contains streaming metadata and a MIME-type suitable for the 
streaming metadata. See also, for example, the discussion at page 13, lines 12-14 of the 
specification with respect to information contained in the streaming metadata, such as 
which file to stream (identification), which streaming server to contact (location), which 
streaming protocol to use (format). 

The present invention as further defined in independent claim 18 requires a step of 
returning the metafile and the MIME-type back from the metadata server to the client 
computer. See, for example, the discussion at page 13, lines 4-6 of the specification with 
respect to transferring the HTTP response that contains the streaming metadata and the 
MIME-type from a network interface 134 on the metadata server 104 to a network 
interface 124 on the web client 102 (arrow 162). 

The present invention as also defined in independent claim 18 requires a step of 
starting a media player on the client computer based on the MIME-type, wherein the 
media player is started by a browser application running on the client computer. In 
addition, the present invention as further defined in independent claim 18 requires a step 
of forwarding the metafile from the browser application to the media player. See, for 
example, the specification at page 13, lines 8-11. 
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The present invention as still further defined in independent claim 18 requires a 
step of extracting information from the metafile, wherein the extracted information is 
extracted from the metafile by the media player and includes information identifying a 
streaming server to contact and a streaming protocol to use. In addition, the present 
invention as defined in independent claim 18 requires a step of composing a streaming 
protocol request based on the extracted information. See, for example, the specification 
at page 13, lines 12-17. 

Still further, the present invention as defined in independent claim 1 8 requires the 
step of forwarding the streaming protocol request from the client computer to the 
streaming server identified in the extracted information. See, for example, the discussion 
at page 13, lines 18-19 of the specification with respect to sending the streaming protocol 
request from the network interface 124 on the web client 102 to a network interface 146 
on a deliver server 106 (arrow 170). 

Finally, the present invention as defined in independent claim 18 requires the step 
of sending a streaming protocol reply and data packets from the streaming server to the 
client computer in response to receiving the streaming protocol request. See, for 
example, the discussion at page 14, lines 1-1 1 of the specification with respect to 
returning a streaming protocol reply and sending data packets from the network interface 
146 on the delivery server 106 to the network interface 124 on the web client 102 
(arrow 176). 
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(vi) Grounds of rejection to be reviewed on appeal 

A. Whether claims 1-4, 6-7, 11-14 and 16-18 are unpatentable under 35 U.S. C. 
§ 102(e) as being anticipated by Klemets et al. (U.S. Patent Application Publication No. 
US2003/0236912 Al)? 

B. Whether claims 5 and 15 are unpatentable under 35 U.S.C. §103(a) over 
Klemets et al. (U.S. Patent Application Publication No. US2003/0236912 Al) over 
"knowledge possessed by a person of ordinary skill in the art"? 
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(vii) Argument 

A. Issue: Whether claims 1-4, 6-7, 11-14 and 16-18 are unpatentable under 35 
U.S.C. §1 02(e) as being anticipated by Klemets et al (U.S. Patent Application 
Publication No. US2003/0236912 Al)? 

Claims 1-4, 6-7, 1 1-14 and 16-18 are rejected under 35 U.S.C §102(e) as being 
anticipated by Klemets et al. (U.S. Patent Application Publication No. US2003/0236912 
Al). 

The appellant respectfully submits that the Klemets et al. reference fails to 
disclose (or even suggest) the invention as recited in claims 1-4, 6-7, 11-14 and 16-18, 
and requests reversal of the rejection under 35 U.S.C. 102(e). 

A proper rejection under 35 U.S.C. §102 requires that the reference disclose each 
and every element of the invention as claimed. However, as discussed below, the 
Klemets et al. reference fails to disclose (or even suggest) the claimed invention. 

Independent claims 1 and 11 (Independent claim 18 argued separately below) 

Independent claims 1 and 1 1 require that a request for a particular media file is 
received from a client computer, and a metafile is returned to the client computer. In 
other words, the client computer requests a particular media file, but receives a metafile 
associated with the media file instead of receiving the requested media file. See, for 
example, FIG. 1 of the present application in which this interaction is represented by 
arrow 152 (HTTP request URL) and arrow 162 (HTTP response that contains streaming 
metadata) between web client 102 and metadata server 104. 
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The present invention as defined in independent claims 1 and 1 1 allows static or 
active web pages, for example, to reference the media files directly instead of referencing 
an active page that is parameterised to target the media file. This means the static or 
active web pages need not indicate whether streaming technology is utilized. This 
advantageously allows standard web publishing software to support referential integrity 
between web pages and media files even in the case where streaming technology is 
utilized. See, for example, the discussion of referential integrity at page 7, lines 1-7 of 
the specification. 

Hence, in the case of each of independent claims 1 and 1 1 , a request for a media 
file (i.e., the request references the media file directly) is received but instead of returning 
the content of the resource requested (default HTTP behavior) or executing the resource 
and forwarding it's reply (Java Servlets, CGI scripts) - a metafile is returned. Nowhere 
in the Klemets et al. reference is such a substitution disclosed (or even suggested). 

In the method for streaming a media file over a distributed information system as 
recited in independent claim 1, a download request for the actual media file is intercepted 
and reinterpreted into a request for receiving a corresponding metafile, which is returned 
to the client computer. The metafile contains information about the identification, 
location and format of the media file. Independent claim 1 1 also contains these 
limitations, but in the context of a computer-readable program stored on a computer- 
readable medium. The claimed interception/reinterpretation (i.e., a download request for 
the actual media file is intercepted and reinterpreted into a request for receiving a 
corresponding metafile) is not disclosed (or even suggested) in the Klemets et al. 
reference. 
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Instead, the Klemets et al. reference discloses the client 106 initially sends a real- 
time streaming protocol (RTSP) DESCRIBE request to the media server 104. Then, the 
media server 104 responds to the RTSP DESCRIBE request with a session description 
protocol (SDP) message. The SDP message includes a streaming media format file 
header and the content description list. See, Klemets et al., page 3, paragraph [003 1]. In 
other words, the client 106 sends a description request (e.g., an RTSP DESCRIBE 
request) to the server 104 to describe the available content. See, Klemets et al., page 4, 
paragraph [0041]. The Klemets et al. reference further discloses the client 106 next sends 
a playback request (e.g., an RTSP SETUP request) for each stream that the client 106 has 
chosen. The client 106 may also send a RTSP PLAY request for each stream that has 
been chosen to initiate delivery of the chosen streams. Finally, in response to the 
playback request, the media server 104 sends the selected streams (e.g., via real-time 
transport protocol (RTP)) to the client 106. See, Klemets et al., pages 4-5, paragraph 
[0045]. 

Contrary to the examiner's assertion in his "Response to Arguments" on pages 7- 
10 of the final Office action, the first communication session in the Klemets et al. 
reference (i.e., sending the RTSP DESCRIBE request and returning the SDP message) 
between the client and the media server does not correspond to the claimed steps of 
receiving a request for a particular media file from a client computer (which step itself 
comprises the steps of intercepting a download request for the actual media file, and 
reinterpreting the download request into a request for receiving a corresponding metafile) 
and returning a metafile. 

The RTSP DESCRIBE request disclosed in the Klemets et al. reference is clearly 
not a request for a particular media file as required by each of independent claims 1 and 
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1 1 . The RTSP DESCRIBE request disclosed in the Klemets et al. reference is merely a 
request from the client to the server to describe the available content. See, Klemets et al., 
page 2, paragraph [0015] and paragraph [0016]; and page 4, paragraph [0041]. More 
particularly in this regard, the RTSP DESCRIBE request does not involve the steps of 
intercepting a download request for the actual media file , and reinterpreting the download 
request into a request for receiving a corresponding metafile as further required by each 
of independent claims 1 and 1 1 . 

Therefore, the appellant respectfully submits that the Klemets et al. reference fails 
to disclose (or even suggest) the invention as recited in independent claims 1 and 1 1 and 
requests reversal of the rejection thereof under 35 U.S.C. 102(e). 

Dependent claims 2-4, 6-7, 12-14 and 16-17 

Claims 2-4, 6-7, 12-14, and 16-17 depend, directly or indirectly, from independent 
claim 1 or 1 1. The appellant respectfully submits that the Klemets et al. reference cannot 
render unpatentable these dependent claims for at least the reasons discussed above with 
respect to independent claims 1 and 11. 

Therefore, the appellant respectfully submits that the Klemets et al. reference fails 
to disclose (or even suggest) the invention as recited in dependent claims 2-4, 6-7, 12-14, 
and 16-17 and requests reversal of the rejection thereof under 35 U.S.C. 102(e). 
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Independent claim 18 

The appellant initially points out that independent claim 18 contains limitations 
corresponding to those argued above with respect to independent claims 1 and 11. 
Therefore, the appellant respectfully submits that the Klemets et al. reference cannot 
render unpatentable independent claim 18 for at least the reasons discussed above with 
respect to independent claims 1 and 11. 

Moreover, independent claim 18 is directed to a method for streaming a media file 
over a distributed information system to a client computer by sequentially interacting 
with two different servers ~ the first being a metadata server and the second being a 
streaming server. See, for example, the discussion of the web client 102, the metadata 
server 104 and the delivery server 106 at pages 10-14 of the specification, with reference 
to FIG. 1. 

Hence, the method for streaming a media file as recited in independent claim 18 
requires the use of two distinct servers, i.e., the metadata server and the streaming server. 
In fact, independent claim 18 requires that a metafile returned to the client computer from 
the metadata server includes information identifying the streaming server to contact with 
a streaming protocol request. The claimed arrangement is entirely different than the 
interaction disclosed in the Klemets et al. reference, which merely occurs between a client 
and a media server. Moreover, the claimed arrangement is advantageous in several 
respects. For example, one metadata server may cooperate with multiple delivery servers 
in order to perform load balancing. See, for example, the discussion of this advantage at 
page 11, lines 4-7 of the specification. The Klemets et al. reference fails to disclose (or 
even suggest) a method for streaming a media file utilizing both a metadata server and a 
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streaming server as recited in independent claim 18, and the advantages that flow 
therefrom. 



In his "Response to Arguments" of the Advisory Action, the examiner states: 

On page 8 of Applicant's remarks, Applicant argues that "claim 18 
is directed to a method for streaming a media file by sequentially 
interacting with two different servers - the fist being a metadata server and 
the second being a steaming server/ 5 However, it is noted that there is no 
explicit definition in the instant specification for the term "server." 
Therefore, "server" is being given the broadest reasonable interpretation 
from the perspective of a person of ordinary skill in the art in light of the 
specification, which is that a server is a hardware device or software that 
serves content or provides a service to another device. This interpretation 
is supported, for example, in claim 11, where the functions of the server 
are being performed by a computer-readable program. Therefore, there is 
no requirement that the media server and the streaming server be hardware 
servers, or even separate hardware servers. As a server in the instant claim 
also includes software, the software code that performs the functions of the 
metadata server in Klemets constitutes a "metadata server," and the 
portion that provides the media file constitutes a streaming server. 
Further, it is noted that separation of known components is not necessarily 
patentable distinction (See MPEP 2144.04 V C). (Advisory Action, 
paragraph bridging pages 2-3.) 

Contrary to the examiner's assertion above, the specification explicitly defines a "server" 
as a computer that provides some service for other computers connected to it via a 
network. See, specification, page 2, lines 16-19. The web client 102, the metadata server 
104 and the delivery server 106 are disclosed as being mutually connected by a network . 
See, specification, page 10, lines 5-6. Likewise, the sole illustrated embodiment (FIG. 1) 
shows the metadata server 104 and the delivery server 106 as being separate computer 
systems (each computer system having its own network interface). Granted, the metadata 
server 104 and the delivery server 106 may be implemented in software. Nonetheless, 
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such software is run on two separate computer systems. See, for example, the discussion 
of the metadata server 104 at page 10, lines 14-15 of the specification and the discussion 
of the delivery server 106 at page 11, lines 1-2 of the specification. 

Independent claim 18 presents the metadata server and the streaming server as two 
distinct servers. Because the metadata server and the streaming server are distinct, the 
metadata server needs to let the client computer know information identifying the 
streaming server to contact. Hence, as pointed out above, independent claim 18 requires 
that the metafile returned to the client computer from the metadata server includes 
information identifying the streaming server to contact with a streaming protocol request. 
The SDP message disclosed in the Klemets et al. reference does not contain information 
identifying a streaming server to contact. No such information is needed in arrangement 
disclosed in the Klemets et al. reference because the interaction therein occurs exclusively 
between a client and a media server. 

Therefore, the appellant respectfully submits that the Klemets et al. reference fails 
to disclose (or even suggest) the invention as recited in independent claim 18 and requests 
reversal of the rejection thereof under 35 U.S.C. 102(e). 
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B. Issue: Whether claims 5 and IS are unpatentable under 35 U.S.C. §103 (a) 
overKlemets et al. (U.S. Patent Application Publication No. US2003/0236912 Al) over 
"knowledge possessed by a person of ordinary skill in the art"? 

Claims 5 and 15 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Klemets et al. (U.S. Patent Application Publication No. US 2003/0236912 Al) over 
"knowledge possessed by a person of ordinary skill in the art". 

Claims 5 and 15 depend, directly, from independent claim 1 and 11, respectively, 
and set forth all of the limitations therein. Accordingly, for at least the reasons discussed 
above with respect to independent claims 1 and 1 1, the appellant respectfully submits that 
dependent claims 5 and 15 also patentably define over the prior art. 

The examiner alleges (without objective evidence of a basis in fact for this 
allegation) the knowledge possessed by a person of ordinary skill in the art cures the 
deficiencies of the Klemets et al. reference with respect to the "checking predefined filter 
criteria determining of whether or not a metafile is to be returned instead of the requested 
media file" limitation of dependent claims 5 and 15. The appellant does not agree - the 
examiner has not shown, for example, that the variation he suggests was within the skill 
level of a person of ordinary skill in the art, was a predictable variation, or was used to 
improve similar devices in the same way. 

In his "Response to Arguments" on pages 7-10 of the final Office action, the 
examiner states, "applicant has not provided adequate information or argument so that on 
its face it creates reasonable doubt regarding the assertion of what is known in the art." 
Here too, the appellant does not agree. The examiner has shown no objective evidence 
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that a person skilled in the art would have employed the claimed choice (i.e., whether or 
not a metafile is to be returned instead of a requested media file) in the first place, and 
further that such a person would have made this choice by "checking predetermined filter 
criteria". The claimed choice is not disclosed in or suggested by the Klemets et al. 
reference. Nor does the Klemets et al. reference disclose or suggest making this choice 
on the claimed basis of "checking predetermined filter criteria". Instead, the examiner 
asserts that the "knowledge possessed by a person of ordinary skill in the art" cures these 
deficiencies. However, the examiner has not provided any evidence that it was 
conventional in the art to 1) provide the claimed choice and 2) to make this choice on the 
claimed basis of "checking predetermined filter criteria". 

The suggestion for the variation suggested by the examiner can be found only 
from using the applicants' invention as a template through a hindsight reconstruction of 
applicants' claims. It is improper to use the inventor's patent application as an instruction 
book on how to reconstruct the prior art. Panduit Corp. v. Dennison Mfg. Co., 810 F.2d 
1561, 1 USPQ2d 1593 (Fed. Cir. 1987). 

In his "Response to Arguments" of the Advisory Action, the examiner states: 

Therefore, the limitation added by claims 5 and 15 are met if a 
server is capable of checking incoming requests to determine if the request 
was a request for download or a request to stream. (Advisory Action, first 
paragraph on page 5.) 

However, the examiner has not shown any objective evidence that such a server was 
within the skill level of a person of ordinary skill in the art at the time the invention was 
made. Moreover, even if such a server was within the skill level of a person of ordinary 
skill in the art (i.e., the server is capable of checking incoming requests to determine if the 
request was a request for download or a request to stream), it would not have been 
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obvious to one of ordinary skill in the art to perform such a checking operation in the 
context of the claimed step of reinterpreting a download request set forth in claims 5 and 
15. That is, the examiner has not demonstrated the motivation of one of ordinary skill in 
the art in reinterpreting an incoming request determined to be a download request (i.e., 
reinterpreting the download request as a request for receiving a corresponding metafile) 
when the server has already checked to determine if the incoming request was a request to 
stream. 

The appellant respectfully submits that the Klemets et al. reference and 
"knowledge possessed by a person of ordinary skill in the art", alone and in combination, 
fail to disclose or suggest the invention as recited in claims 5 and 15 and requests reversal 
of the rejection under 35 U.S.C. 103(a). 

D. Conclusion to argument 

In view of the above arguments, the appellant respectfully submits that claims 
1-7 and 1 1-18 are patentable over the cited art references, and the rejections thereof under 
35 U.S.C. 102(e) and 35 U.S.C. 103(a) should be reversed. 



Respectfully submitted, 
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(viifl Claims appendix 



1 LA method for streaming a media file over a distributed information system to a client 

2 computer running a browser application, the method comprising the steps of: 

3 receiving a request for a particular media file from a client computer, 

4 providing a metafile, wherein said metafile contains information about the 

5 identification, location and format of the media file, 

6 returning said metafile back to said client computer, 

7 characterized in that 

8 the step of receiving a request for a particular media file from a client computer 

9 comprises the steps of : 

1 0 intercepting a download request for the actual media file and 

1 1 reinterpreting said download request into a request for receiving a corresponding 

12 metafile. 

1 2. The method according to claim 1, wherein the step of reinterpreting said download 

2 request includes the step of deriving information about said corresponding metafile from 

3 a portion of the URL. 
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1 3. The method according to claim 2, wherein said portion of the URL is the file 

2 extension of the requested media file. 

1 4. The method according to claim 1, wherein the step of providing a metafile comprises 

2 one of the steps of: 

3 dynamically generating a metafile, and 

4 statically querying a metafile from a data store. 

1 5. The method according to claim 1 , wherein the step of reinterpreting said download 

2 request includes the step of: 

3 checking predefined filter criteria determining of whether or not a metafile is to be 

4 returned instead of the requested media file. 

1 6. The method according to claim 1, wherein the step of providing a metafile further 

2 includes the step of retrieving information about the configuration of at least one item 

3 chosen from the group comprising: version of the streaming product, type of the 

4 streaming product, location of the media file, load of the servers, load of the network, 

5 location of the client, quality of service. 
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1 7. The method according to claim 1, wherein the step of providing a metafile further 

2 includes the step of reading information about the clients preferred streaming format and 

3 forming a metafile in accordance with the clients preference. 

1 1 1 . A computer-readable program stored on a computer-readable medium, said computer 

2 readable program being configured to perform the steps of: 

3 receiving a request for a particular media file from a client computer, 

4 providing a metafile, wherein said metafile contains information about the 

5 identification, location and format of the media file, 

6 returning said metafile back to said client computer, 

7 characterized in that 

8 the step of receiving a request for a particular media file from a client computer 

9 comprises the steps of : 

1 0 intercepting a download request for the actual media file and 

1 1 reinterpreting said download request into a request for receiving a corresponding 

12 metafile. 

1 12. The computer-readable program of claim 1 1 , wherein the step of reinterpreting said 

2 download request includes the step of deriving information about said corresponding 

3 metafile from any portion of the URL. 
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1 13. The computer-readable program of claim 12, wherein said portion of the URL is the 

2 file extension of the requested media file. 

1 14. The computer-readable program of claim 1 1 , wherein the step of providing a metafile 

2 comprises one of the steps of: 

3 dynamically generating a metafile, and 

4 statically querying a metafile from a data store. 

1 15. The computer-readable program of claim 11, wherein the step of reinterpreting said 

2 download request includes the step of: 

3 checking predefined filter criteria determining of whether or not a metafile is to be 

4 returned instead of the requested media file. 

1 16. The computer readable program of claim 11, wherein the step of providing a metafile 

2 further includes the step of retrieving information about the configuration of at least one 

3 item chosen from the group comprising: version of the streaming product, type of the 

4 streaming product, location of the media file, load of the servers, load of the network, 

5 location of the client, quality of service. 
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1 17. The computer readable program of claim 1 1, wherein the step of providing a metafile 

2 further includes the step of reading information about the client's preferred streaming 

3 format and forming a metafile in accordance with the client's preference. 

1 18. A method for streaming a media file over a distributed information system to a client 

2 computer running a browser application, the method comprising the steps of: 

3 receiving, at a metadata server, a request for a particular media file from a client 

4 computer, 

5 providing, at said metadata server, a metafile and a MIME-type, wherein said 

6 metafile contains information about the identification, location and format of the media 

7 file, 

8 returning said metafile and said MIME-type back from said metadata server to 

9 said client computer, 

1 0 starting a media player on said client computer based on said MIME-type, wherein 

1 1 said media player is started by a browser application running on said client computer, 

12 forwarding said metafile from said browser application to said media player, 

1 3 extracting information from said metafile, wherein the extracted information is 

14 extracted from said metafile by said media player and includes information identifying a 

1 5 streaming server to contact and a streaming protocol to use, 

1 6 composing a streaming protocol request based on said extracted information, 
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1 7 forwarding said streaming protocol request from said client computer to said 

1 8 streaming server identified in said extracted information, 

19 sending a streaming protocol reply and data packets from said streaming server to 

20 said client computer in response to receiving said streaming protocol request, 

2 1 characterized in that 

22 the step of receiving a request for a particular media file from a client computer 

23 comprises the steps of : 

24 intercepting a download request for the actual media file and 

25 reinterpreting said download request as a request for receiving a 

26 corresponding metafile. 
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(ix) Evidence appendix 

NONE. 
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(x) Related proceedings appendix 

NONE. 
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